The Windows Embedded operating system includes functionality that can prevent the content of a storage medium from being changed. In a typical example, it may be desirable to prevent the operating system image, which may be stored on a particular disk partition or on flash media, from being changed at runtime. To accomplish this, Windows Embedded provides a file-based write filter which operates at the file level and a block-based write filter (or enhanced write filter) that operates at the block level to redirect all writes that target a protected volume to a RAM or disk cache called an overlay. This overlay stores changes made to the operating system at runtime but is removed when the device is restarted thereby restoring the device to its original state.
FIG. 1 illustrates how a file-based write filter 110 can be employed to prevent the contents of a protected volume on disk 100 from being modified. Disk 100 is intended to generally represent any type of physical storage medium (or volume). In accordance with the Windows architecture, a driver stack consisting of file system driver 111, volume manager 112, and disk driver 113 sit atop disk 100, and I/O manager 120 manages the flow of I/O requests through the driver stack. An application (not shown) can employ file/directory management APIs 160 to invoke a service of system services 130 (e.g., by calling ReadFile, WriteFile, CreateFile, etc. on a particular file) which will result in I/O manager 120 creating an IRP for the request. This IRP will then be passed down through the driver stack.
As depicted in FIG. 1, file-based write filter 110 is positioned at the top of the driver stack and will therefore be able to process an IRP prior to the IRP being passed down to the lower level drivers. File-based write filter 110 can be configured to detect writes targeting a protected volume and redirect them to overlay 140 rather than allowing them to be passed down the driver stack. As a result, the write will actually occur in overlay 140 rather than to disk 100. File-based write filter 110 can be further configured to detect reads that target content that was previously redirected to overlay 140 and redirect these reads to overlay 140. In this way, even though it will appear to the application that the content of disk 100 is being updated, the updates are actually being temporarily maintained in overlay 140. The contents of overlay 140 can be maintained until the operating system is restarted or until an explicit command is received to discard the contents of the overlay.
Even when file based write filter 110 is employed, it may still be desirable to allow certain files to be modified on disk 100. To enable this, file-based write filter 110 includes an exclusion list which identifies any file or directory that file-based write filter 110 should allow to be modified. An application can add a file or directory to this exclusion list using write filter APIs 150. For example, the FbwfAddExclusion function allows an application to specify a file or directory to be excluded. When file-based write filter 110 receives a write request that targets a file or directory that is included in the exclusion list, it will allow the write request to proceed down the driver stack in a normal fashion such that the write will occur on disk 100. Similarly, even if a file has been redirected to overlay 140, an application may employ the FbwfCommitFile function to cause the file in overlay 140 to be persisted to disk 100. The ability to add files and directories to the exclusion list as well as the ability to commit files in the overlay to disk creates a backdoor that can be exploited by malicious code.